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(54) Object oriented interprocess communication system 



(57) The present invention is a method and system 
for providing a common communications interface be- 
tween a plurality of programs through a communications 
network. The system includes an adapter object (2b) re- 
sponsive to a first one of the plurality of programs for 
connecting to the communications network; a resource 
object (2c) coupled to the adaptor object (2b) and also 
associated with the first one of the plurality of programs 
for storing at least one identifier associated with the first 



one of the plurality of programs in the memory of the 
computer and responsive to an agent object (2d) asso- 
ciated with a second one of the plurality of programs for 
generating a view object (2e) for accepting communica- 
tions through said communications network; and a data 
object (2f) coupled to the agent object (2d) and to the 
view object (2e) for storing the data transmitted between 
the plurality of programs. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

The present invention relates to an object oriented 
method and system for providing a common communi- 
cations interface between software application pro- 
grams, 

BACKGROUND OF THE INVENTION 

Communication between software applications and 
the programs which comprise the applications is an im- 
portant issue in any computer system. One method of 
providing for such communications is through an appli- 
cation program interface (API). Several different API's 
are available for facilitating communication between ap- 
plication programs including Berkeley Sockets, IBM's 
CPI-C, Microsoft's NetBEUI, WinSock and PeerLogic's 
PIPES Platform™. 

For general reference see Comer, Douglas E and 
Steven's, David L., "Internetworking with TCP/IP", vol. 
Ill, Prentice-Hall, (1993); PIPES "Platform User's Guide 
and reference Manual", PeerLogic, Inc., (1993); 
"X/Open Transport Interface (XTI)", X/Open CAE Spec- 
ification, X/Open Company Limited, (1 992): Stevens ; W. 
Richard, 'Unix Network Programming", Prentice-Hall. 
(1990); "Common Programming Interface Communica- 
tions Reference", Fourth Edition, IBM, (1991); Schmidt, 
Douglas ; "Concurrent O-O Network Programming With 
C++", C++ World, (1994); and Bach, Maurice J., "The 
Design of the Unix Operating System", Prentice-Hall : 
(19S6). 

Each of the API's, however, has advantages and 
disadvantages which make it a better or worse choice 
than using another of the API's under similar circum- 
stances. And, in many cases, it may be necessary for 
one application to use more than one of the API's be- 
cause two or more applications with which it needs to 
communicate are using different ones of the API's avail- 
able. 

Thus, programming an application to use only one 
of the API's means that the application will not operate 
at peak performance under some circumstances. How- 
ever, reprogramming the application to use a different 
API when circumstances change can become time con- 
suming and increases the opportunity to introduce er- 
rors into the application because of the operational nu- 
ances of each API. 

Thus, it is desirable to have a common API which 
can be used to communicate with a variety of other 
API's. 

Furthermore, as more efficient and/or more flexible 
API's become available, the desire to use the new API 
to take advantage of the latest features or to remedy 
past problems will sometimes necessitate a conversion. 
It is desirable to do such a conversion with minimum, if 
any, impact to the application. 



These system can be described in terms of object 
models, functional models and dynamic models as dis- 
cussed by James Rumbaugh et al. in the book Object- 
Oriented Modeling and Design published in 1991 by 
5 Prentice-Hall (the "OOMD"). According to the book 
OOMD : an object model of a system describes the ob- 
ject types which comprise the system and also shows 
the relationships between the object types. A functional 
model of the system shows the processes and data 
70 structures of the system and the flow of data therebe- 
tween but does not indicate the sequence of processing. 
The dynamic model of the system does show the 
processing sequence of the system. That sequencing is 
shown primarily as transitions from one state to another. 

Thus, what is needed is a method and system for 
providing a common communications interface between 
software application programs. 

SUMMARY OF THE INVENTION 

20 

The present invention is a method and system 
which provide a common communications interface be- 
tween a plurality of different types of software applica- 
tion programs through a communications network. The 

25 system and method include an Adapter means associ- 
ated with and responsive to one of said plurality of pro- 
grams for connecting said one of said plurality of pro- 
grams to said communications network. 

Accordingly the present invention provides a com- 

30 puter implemented system for providing a common 
communications interface between a plurality of pro- 
grams through a communications network, the system 
comprising, adapter means responsive to a first one of 
said plurality of programs for connecting said first one 

55 of said plurality of programs to said communications net- 
work, resource means coupled to said adaptor means 
and associated with said first one of said plurality of pro- 
grams for storing at least one identifier associated with 
said first one of said plurality of programs in a memory 
and responsive to an agent means associated with a 
second one of said plurality of programs for generating 
view means associated with said second one of said plu- 
rality of programs to accept communications from said 
second one of said plurality of programs through said 

45 communications network, view means coupled to said 
resource means and responsive to said second one of 
said plurality of programs for accepting data transmitted 
from said second one of said plurality of programs to 
said first one of said plurality of programs; and data 

so means coupled to said view means for storing said data 
transmitted between said first one of said plurality of pro- 
grams and said second one of said plurality of programs. 

The present invention further provides a method of 
providing data communication between a plurality of 

55 programs through a communications network, compris- 
ing, connecting a first one of said plurality of programs 
to said communications network using an adapter 
means, initializing said first one of said plurality of pro- 
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grams for receiving communications from a second one 
of said plurality of programs using a resource means as- 
sociated with said first one of said plurality of programs, 
attaching said second one of said plurality of programs 
to said resource means associated with said first one of 
said plurality of programs using an agent means asso- 
ciated with said second one of said plurality of programs, 
generating a view means in response to said agent 
means associated with said second one of said plurality 
of programs for transmitting data to and receiving data 
from said second one of said plurality of programs, stor- 
ing said data in a data means associated with said first 
one of said plurality of programs. 

Also included is a Resource means associated with 
the Adaptor means and with one of the plurality of soft- 
ware application programs. The Resource means 
stores at least one identifier, or Resource Name, asso- 
ciated with the software application programs in a Name 
Space. The Resource means is also responsive to an 
Agent means associated with another of the plurality of 
software application programs and generates a View 
means associating the first software application pro- 
gram with the second software application program. Tht 
View means accept communications from the software 
application programs through said communications net- 
work. 

The View means, coupled to the Resource means 
of one software application program, is responsive to 
another software application program and accepts the 
data transmitted between the two programs. 

The system and method also include Data means, 
coupled to the View means, which stores the data trans- 
mitted between the software application programs. 

BRIEF DESCRIPTION OF THE DRAWINGS 

For a better understanding of the present invention, 
reference may be made to the accompanying drawings, 
in which: 

Fig. 1 A illustrates a first embodiment of the present 
invention; 

Fig. 1B illustrates a second embodiment of the 
present invention; 

Fig. 1 C illustrates a third embodiment of the present 
invention; 

Fig. 2 illustrates an object model of one embodi- 
ment ofthe present invention; 
Fig. 3 illustrates an object model of the Name Space 
Iterator object type of one embodiment of the 
present invention; 

Fig. 4 illustrates a dynamic model of the Name 
Space Iterator object of one embodiment of present 
invention; 

Fig. 5 shows an object mode! of the Adapter object 
type of one embodiment of the present invention; 
Figs. 6-8 depict dynamic models of the Adapter 
object of one embodiment of the present invention; 



Fig. 9 shows an object model of the Resource object 
of one embodiment of the present invention; 
Figs. 10-14 illustrate dynamic models of the 
Resource object of one embodiment of the present 

5 invention; 

Fig. 15 illustrates an object model of the Agent 
object of one embodiment of the present invention; 
Figs. 16-19 show dynamic models illustrating the 
general operation of the Agent object of one embod- 

10 iment of the present invention; 

Fig. 20 illustrates an object model of the View object 
of one embodiment of the present invention; 
Figs. 21-24 depict dynamic models illustrating the 
general operation of the View object of one embod- 

15 iment of the present invention; 

Fig. 25 shows an object model of the Data object of 
one embodiment of the present invention; 
Fig. 26 illustrates one embodiment of an application 
using one embodiment of the present invention; and 

20 Fig. 27 depicts one embodiment of a client/server 
application using one embodiment of the present 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

25 

The present invention is a method and system for 
providing a common communications interface between 
a plurality of software application programs and at least 
one communications network interface. 
30 Fig. 1A illustrates one embodiment of the present 
invention where a plurality of software application pro- 
grams 1a through 1b are coupled to at least one com- 
munications network interface Id by the Transport 
Framework 1c of the present invention. In the embodi- 
es ment of the present invention illustrated in Fig. 1A, the 
plurality of software application programs lathrough 1b, 
the Transport Framework 1c and the communications 
network interface 1d are all implemented on a general 
purpose computer which includes a processor 1g, a 
io memory 1 x, a display 1y and data storage 1z. Further- 
more, the software programs 1a through 1b in this em- 
bodiment of the present invention share the same ad- 
dress space in the processor 1g. The software applica- 
tions program 1a and the software applications program 
45 1 b may belong to the same application. 

Fig. 1B illustrates another embodiment of the 
present invention which facilitates communication be- 
tween a first set of software application programs 1f 
through 1h on a first processor 1o and a second set of 
50 software application programs 1k through 11 on a sec- 
ond processor 1 p. The first processor 1 o includes a first 
implementation of the Transport Framework 1i which 
couples the first set of software application programs 1f 
through 1h to a first communications network interface 
55 ij. The second processor 1p includes a second imple- 
mentation of the Transport Framework 1m which cou- 
ples the second set of software application programs 1 k 
through 11 to a second communications network inter- 
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face In. 

Fig. 1C illustrates a third embodiment of a system 
using the present invention in which the software appli- 
cation programs 1a through 1 b, using the first Transport 
Framework 1c and a first implementation ofthecommu- s 
nications network interface (A) 1j, where (A) represents 
the type of communications network interface, e.g., a 
PIPES Platform™ implementation, communicate with 
the software application programs 1f through ih which 
use the second Transport Framework 1 i and the first im- io 
plementation of the communications network interface 
(A) lj. Similarly, the software application programs 1a 
through 1b, using the first Transport Framework 1c and 
a second implementation of the communications net- 
work interface (B) 1n, where (B) represents, for exam- is 
pie, a WinSock implementation of the communications 
network interface, communicate with the software appli- 
cation programs 1k through 11 which use the Transport 
Framework implementation 1m and the second imple- 
mentation of the communications network interface (B) 20 
1n. This embodiment is used where, for example, the 
software application programs 1a through 1b do not 
share the same address space as the software applica- 
tion programs 1 k through 1 1 in the processor 1 g. 

Fig. 2 illustrates one embodiment of an object mod- 25 
el of the Transport Framework 1c of the present inven- 
tion. 

The object types associated with the Transport 
Framework ofthe present invention, as illustrated in the 
object model shown in Fig. 2, include a Name Space 30 
Iterator object type 2a, an Adapter object type 2b, a Re- 
source object type 2c, an Agent object type 2d, a View 
object type 2e and a Data object type 2f Each ofthe ob- 
ject types shown in Fig. 2 may also include associated 
data structures and behaviors (or operations). Instanti- 35 
ations of an object type are referred to as objects or ob- 
ject instances. Instantiations of the data structures and 
behaviors associated with an object type are referred to 
as attributes and methods, respectively. 

The object instances and associated attributes and -to 
methods for each ofthe object types illustrated in Fig 2 
are shown in Figs. 3, 5, 9, 15, 20 and 25. Instantiations 
of object types, data structures and behaviors are cre- 
ated when a software application program requests 
services from a particular implementation of the Trans- *s 
port Framework 1c of the present invention as described 
in more detail hereinbelow. 

Execution of the methods associated with a behav- 
ior or the generation of events can transition the asso- 
ciated object instances from one state to another. The so 
various states and transitions associated with object in- 
stances of each of the object types shown in Figs. 3, 5, 
9, 1 5, and 20 are illustrated in Figs. 4, 6-8, 1 0-1 4, 1 6-1 9, 
and 21-24, respectively. 

Using the embodiment of the present invention as ss 
illustrated in Fig. 2, a first software application program 
1 a creates an instance of the Adapter object type 2b as- 
sociated with a particular communications network im- 



plementation 1 d and creates at least one instance of the 
Resource object type 2c associated with the instance of 
the Adapter object type 2b, available for communication 
with a second software application program 1b which 
has also created an instance of the Adapter object type 
2b associated with the same communications network 
implementation 1c. For the second software application 
program 1 b to initiate communications with the first soft- 
ware application program 1a, the second software ap- 
plication program 1b creates an instance of the Agent 
object type 2d associated with the instance of the Adapt- 
er object 2b. 

The second software application program 1b cre- 
ates an instance ofthe Name Space Iterator object type 
2a to look up a Resource Name associated with the first 
software application program 1a. Using the Resource 
Name, the instance of the Agent object type 2d associ- 
ated with the second software application program 1b 
then attaches to the instance of the Resource object 
type 2c associated with the first software application 
program 1a. 

In response to the attachment by the instance of the 
Agent object type 2d associated with the second soft- 
ware application program 1b, the instance of the Re- 
source object type 2c associated with the first software 
application program 1a generates an instance of the 
View object type 2e. Through the instance of the View 
object type 2e, the second software application program 
1 b then transmits data to and receives data from the first 
software application program 1a using instances of the 
Data object type 2f. 

The operations of each of the object types which 
comprise the Transport Framework 1c are discussed in 
more detail hereinbelow. 

Fig. 3 illustrates the object model for the Name 
Space Iterator object type 2a. The Name Space Iterator 
object type 2a includes the behaviors new(), delete(), 
reset(), set() and findnext(). Using the Name Space It- 
erator object type 2a, the second application program 
1b searches through a Name Space 2g associated with 
the communications network implementation 1d to find 
an active Resource Name associated with the first soft- 
ware application program 1a. The Resource Name is 
used to attach instances of the Agent object type 2d to 
instances of the Resource object type 2c. The reset() 
behavior starts the iteration at the "top" of the Name 
Space 2g. The set() behavior allows the userto initialize 
search criteria for the findnext() behavior which then re- 
turns the Resource Name which satisfies the search cri- 
teria. 

The dynamic model of the Name Space Iterator ob- 
ject type 2a, shown in Fig. 4, shows the state transitions 
when the second software application program 1b in- 
vokes the methods corresponding to the behaviors as- 
sociated with the Name Space Iterator object type 2a. 
The states associated with the Name Space Iterator ob- 
ject type 2a include an Initialized state 4a, a Set state 
4b, a Reset state 4c, a Finding state 4d and a Next state 
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4e. 

The Finding state 4d includes the one behavior, to 
be implemented by the communications network inter- 
face 1 d, associated with the Name Space Iterator object 
type 2a which is to find a given Resource Name in the 
Name Space 2g which matches a given search criteria. 
Once the Resource Name associated with the software 
application program 1a is found, communications with 
that software application program 1a can be initialized. 
To prevent another software application program 1b 
from initiating communications with the software appli- 
cations program 1a, no Resource Name for the software 
application program 1a would exist in the Name Space 

2g. 

ADAPTER 

The Adapter object type 2b, shown in detail in the 
object model in Fig. 5, along with the Name Space Iter- 
ator object type 2a, provides a management interface 
for Agent object types 2d and Resource object types 2c 
associated with a particular communications network 
implementation 1d. The management interface provid- 
ed by the Adapter object type 2d includes management 
operations such as creating, modifying and removing 
associations between application programs and Re- 
source object types 2c, between Resource object types 
2c and communications network implementations 1d 
and between Resource object types 2c and Agent object 
types 2d. 

The Agent object type 2d associated with a partic- 
ular instance of an Adapter object type 2b are stored in 
the data structure Set of Agents 5b. Instances of a Re- 
source object type 2c associated with a particular in- 
stance of an Adapter object type 2b are stored in the 
data structure Set of Resources 5c. Both the Set of 
Agents 5b and the Set of Resources 5c data structures 
are implemented, for example, as doubly linked lists of 
agent identifiers and resource identifiers in one embod- 
iment of the present invention. 

The behaviors for the Adapter object type 2b in- 
clude new(), deleteQ, connect() and disconnect). The 
connect() behavior connects the software application 
program 1a to the communications network implemen- 
tation 1d. The disconnect) behavior disconnects the 
software application program 1a from the communica- 
tions network implementation 1d. There is one Adapter 
object type 2b for each address space which associates 
the software application program la with the communi- 
cations network implementation 1d. 

Dynamic models of the Adapter object type 2b are 
shown in Figs. 6-8. Fig. 6 shows that, in general, exe- 
cution of the behaviors associated with the Adapter ob- 
ject type 2b transition instances of the Adapter object 
type 2b between at least five states which include a Dor- 
mant state 6a, a Connecting state 6b, a Cleaning state 
6e, a Disconnecting state 6d and an Active state 6c. 

When the software application program 1a suc- 



cessfully creates an instance of the Adapter object type 
2b using the new() behavior the new instance of the 
Adapter object type 2b transitions to the Dormant state 
6a. When creating the new instance of the Adapter ob- 

5 ject type 2b, the software application program 1 a sends 
to the new() behavior an attribute called Adapter Con- 
figuration which includes configuration attribute data 
particular to the communications network implementa- 
tion 1d associated with the new instance of the Adapter 

10 object type 2b. If successful in creating the new instance 
of the Adapter object type 2b, the new() behavior returns 
the attribute Adapter Handle which is used as an iden- 
tifier. 

Once in the Dormant state 6a : the instance of the 

is Adapter object type 2b can either transition to the Con- 
necting state 6b or be deleted. 

If the software application program 1a issues the 
deleteQ behavior while the instance of the Adapter ob- 
ject type 2b is in the Dormant state 6a, the instance of 

20 the Adapter object identified by the attribute Adapter 
Handle is deleted. 

If the application program 1a issues the connect() 
behavior while the instance of the Adapter object type 
2b is in the Dormant state 6a, the instance of the Adapter 

25 object type 2b transitions to the Connecting state 6b. 
While in the Connecting state 6b, the instance of the 
Adapter object type 2b performs any steps required by 
the communications network implementation 1d to ini- 
tialize the software application program 1a to use the 

so communications network implementation 1d. An Error 
attribute is generated by the connect() behavior indicat- 
ing the success or failure in creating the connection. 

When all processing is complete for the Connecting 
state 6b : a connect-done event occurs which transitions 

35 the instance of the Adapter object type 2b to either the 
Dormant state 6a or the Active state 6c depending upon 
the value of the Error attribute. If the value of the Error 
attribute is failure, then the transition is to the Dormant 
state 6a; otherwise the transition is to the Active state 

40 6c. The processing which occurs during the Active state 
6c is further illustrated in the dynamic model shown in 
Fig. 7. 

Fig. 7 shows that the Active state 6c of the instance 
of the Adapter object type 2b includes an Adding Agent 

45 state 7a, a Waiting state 7b, an Adding Resource state 
7c, a Remove Agent state 7d and a Remove Resource 
state 7e which represent the processes done in the Ac- 
tive state 6c of adding to and removing from the Set of 
Agents 5b and the Set of Resources 5c data structures 

5t? instances of the Agent object types 2d and of the Re- 
source object types 2c, respectively in response to the 
software application program 1a. 

As further illustrated in Fig. 6, from the Active state 
6c, the instance of the Adapter object type 2b can tran- 

55 sitiontothe Cleaning state 6e or the Disconnecting state 
6d. The application program 1a. can trigger the discon- 
nect event and cause the instance of the Adapter object 
type 2b to transition to the Disconnecting state 6d by 
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issuing the disconnect) behavior. While in the Discon- 
necting state 6d, the instance of the Adapter object type 
2b performs any operations required by the communi- 
cations network implementation 1 d to terminate the con- 
nection to the application program 1 a. When all process- 
ing is complete for the Disconnecting state 6d, the con- 
nect-gone event is triggered causing the instance of the 
Adapter object type 2b to transition to the Cleaning state 
6e, the operation of which is discussed hereinbelow. 

The connect-gone event can also occur when the 
instance of the Adapter object type 2b is in the Active 
state 6c and is triggered from within the Transport 
Framework 1c when a condition arises in which the ap- 
plication program 1a associated with the instance of the 
Adapter object type 2b can no longer use the commu- 
nications network implementation 1d. This condition is 
usually caused by a catastrophic event such as a soft- 
ware failure of the communications network implemen- 
tation 1d. When the connect-gone event is triggered 
while the instance of the Adapter object type 2b is in the 
Active state 6c, the instance of the Adapter object type 
2b again transitions to the Cleaning state 6e. 

Fig. 8 shows a dynamic model further illustrating the 
Cleaning state 6e of the instance of the Adapter object 
type 2b shown in Fig. 6. The Cleaning state 6e of the 
instance of the Adapter object type 2b includes a Re- 
move Resources state 8a and a Remove Agent state 
6b. Thus, one purpose of the Cleaning state 6e is to re- 
move the associations between instances of the Adapt- 
er object type 2b and instances of the Agent object type 
2d and between instances of the Adapter object type 2b 
and the Resource object type 2c when the Adapter ob- 
ject type 2b is disconnected from the communications 
network interface 1d. The Cleaning state 6e also notifies 
instances of the Agent object type 2d and of the Re- 
source object type 2c that the connection with the com- 
munications network interface 1d is gone. 

RESOURCE 

The Resource object type 2c provides the software 
application program 1a with a means to advertise a 
name for another applications program 1 b to use when 
wanting to communicate with the software application 
program 1a. For example, if the software application 
program 1 a wants to allow the software applications pro- 
gram 1b to communicate with it, then the software ap- 
plication program 1a generates and activates an in- 
stance of the Resource object type 2c. 

The Resource object type 2c also generates and 
manages instances of the View object type 2e ; through 
which communication actually occurs, as discussed in 
more detail hereinbelow. 

Fig. 9 illustrates an object model for the Resource 
object type 2c. As shown in Fig. 9, the behaviors asso- 
ciated with the Resource object type 2c include new() : 
deletef), activateQ and deactivate(). Also associated 
with the Resource object type 2c is the data structure 



Set of Views 9b. 

The new() behavior creates an instance of the Re* 
source object type 2c and associates it with the software 
application program 1a. When creating the instance of 
5 the Resource object type 2c, the software application 
program 1 a uses an Adapter Handle attribute (which as- 
sociates the instance of the Resource object type 2c 
with an active instance of the Adapter object type 2b), 
a Resource Name (an identification name to activate in 

to the Name Space 2g associated with the communica- 
tions network implementation 1d) and a Resource Con- 
figuration attribute which includes data particular to the 
communications network implementation 1d. 

The activateQ behavior activates the instance of the 

T5 Resource object type 2c by placing the associated Re- 
source Name into the Name Space 2g associated with 
the communications network implementation 1d. The 
software application program la can have multiple in- 
stances of the Resource object type 2c associated with 

20 it. However each instance of the Resource object type 
2c must be uniquely named in the Name Space 2g. 

The deactivateQ behavior deactivates the instance 
of the Resource object type 2c by removing the Re- 
source Name associated with the instance of the Re- 

2S source object type 2c from the Name Space 2g. 

As shown in Fig. 10, instances of the Resource ob- 
ject type 2c transition between four states: a Dormant 
state I0a : an Activating state 10b, a Cleaning state 10c 
and an Active state 10d. 

so When an application program 1a successfully cre- 
ates an instance of the Resource object type 2c, the in- 
stance of the Resource object type 2c transitions to the 
Dormant state 10a. Once in the Dormant state 10a : the 
instance of the Resource object type 2c can transition 

35 to the Activating state 10b or be deleted. 

A software application program la issuing the acti- 
vate() behavior will transition to the Activating state 10b 
if the associated instance of the Adapter object type 2b 
is in the Active state 6c. During the Activating state 10b 

^0 the instance of the Resource object type 2c performs 
any steps required by the communications network im- 
plementation 1d to put the Resource Name associated 
with the instance of the Resource object type 2c into the 
Name Space 2g. 

45 When all processing is complete for the Activating 
state 10b, an activate-done event is triggered and the 
instance of the Resource object type 2c will either tran- 
sition to the Dormant state 1 0a or to the Active state 1 0d 
depending upon the value of an Error attribute returned 

so by the activate-done event. If the Error attribute has a 
failure value, the transition is back to the Dormant state 
10a. Otherwise, the instance of the Resource object 
type 2c is added to the data structure Set of Resources 
5c associated with the instance of the Adapter object 

ss type 2b and the instance of the Resource object type 2c 
transitions to the Active state 10d. 

The processing done by the instance of the Re- 
source object type 2c while in the Active state 10d is 
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illustrated in Fig. 11. The instance of the Resource ob- 
ject type 2c, while in the Active state 1 0d is in either the 
Processing state 11a or the Deactivating slate 11b or 
can be in both concurrently. 

The Processing state 11a includes an Attaching 
state 11c, a Waiting state 11 d, a Detaching state 11 e 
and a Removing state 11 f The Attaching state lie and 
the Detaching state 1 1 e are illustrated in more detail in 
the dynamic models shown in Fig. 12 and Fig. 13, re- 
spectively and control the attach and detach of instanc- 
es of the Agent object type 2d with the instance of the 
Resource object type 2c, respectively. 

As shown in Fig. 12, when an instance of the Agent 
object type 2d transmits the attach-by-agent event, the 
instance of the Resource object type 2c transitions to 
the Verifying state 12a after generating a new instance 
of the View object type 2e. If successfully verified, the 
new instance of the View object type 2e is added to the 
Set of Views gb in the Adding state 12b and a listen 
event is sent to the instance of the View object type 2e ; 
thereby transitioning the new instance of the View object 
type 2e from the Dormant state 21a to the Active state 
21b, discussed further hereinbelow. Also, an attach 
done event is sent to the Agent object type 2d verifying 
to the Agent object type 2d that the attach was success- 
ful. 

If the verification is not successful, the attach is re- 
jected and the new instance of the View object type 2e 
is deleted. The instance of the Agent object type 2d at- 
tempting to attach to the instance of the Resource object 
type 2c which initiated the creation of the new instance 
of the View object type 2e is notified that the attach was 
unsuccessful. 

The Detaching state 11 e of the instance of the Re- 
source object type 2c ; illustrated in more detail in Fig. 
1 3, is entered into when the instance ofthe Agent object 
type 2d sends a detach-by-agent event to the instance 
of the Resource object type 2c. in response, the in- 
stance of the Resource object type 2c enters the Re- 
moving state 13e and sends a detach-by-resource 
event to the associated instance of the View object type 
2e, thereby ending the association. The instance of the 
Resource object type 2c then transitions to the Deleting 
state 13b where the reference to the instance of the 
View object type 2e and the instance of the View object 
type 2e are deleted from the Set of Views 9b. Finally 
the detach-done event is sent to the associated instance 
of the Agent object type 2d. 

Returning to the processing shown in the dynamic 
model of Fig. 11, the software application program la 
triggers the deactivate event and transitions the in- 
stance of the Resource object type 2c to the Deactivat- 
ing state 11b within the Active state 10d by calling the 
deactivate() behavior. During the Deactivating state 
11b, the communications network implementation Id 
performs any steps necessary to remove the associated 
Resource Name from the Name Space 2g. 

When completed, a deactivate-finished event is 



generated and synchronized with a second deactivate- 
finished event generated from the Waiting state 11d. 
The synchronization of the deactivating-finished events 
at sync point 11 g signifies that the instance of the Re- 
5 source object type 9a transitions to the Cleaning state 
10c. The instance of the Resource object type 9a can 
also transition to the Cleaning state 1 0c by a deactivate- 
by-adaptor state. The software applications program 1a 
can also be disconnected from the communications net- 
io work implementation 1d by a deactivate-by-adapter 
event generated when the associated instance of the 
Adapter object 2b terminates the connection to the com- 
munications network implementation 1d because of 
some uncontrollable, catastrophic event such as a soft- 

1$ ware or hardware failure of the communications network 
implementation 1d. 

Returning to the operations of the Resource object 
dynamic model shown in Fig. 10, from the Active state 
10d : upon receipt of deactivate-done event or the deac- 

20 tivate-by-adapter event, the instance of the Resource 
object type 2c transitions to the Cleaning state 1 0c. The 
receipt of the deactivate -done event also triggers a re- 
move-resource event which is sent to the associated in- 
stance of the Adapter object 2b. 

25 The Cleaning state 10c is illustrated in detail in Fig. 
1 4. In response to a deactivate-done event from the as- 
sociated instance of the Resource object type 2c or in 
response to a detach-by-adapter event from the asso- 
ciated instance of the Adapter object type 2b, the in- 

30 stance of the Resource object type 2c enters the Re- 
moving state 14a. 

From the Removing state 14a, a detach-by-re- 
source event is sent to the associated instance of the 
View object type 2c and a detach-by-view event is also 

35 sent to the associated instance of the Agent object type 
2d and the instance of the Resource object type 2e tran- 
sitions tothe Deleting state 14b. From the Deletingstate 
1 4b : the associated instance of the View object type 2e 
is deleted and the Resource object type 2e transitions 

JO back to the Removing state 14a. Processing continues 
in this manner until all instances of the View object type 
2e are removed from the Set of Views 9b. Upon com- 
pletion, a clean-done event is triggered, thereby transi- 
tioning the instance of the Resource object type 2e to 

45 the Dormant state 10a. 

AGENT 

The Agent object type 2d provides the application 
50 program 1b with means to send data to and receive data 
from the application program 1a which has activated an 
instance of the Resource object type 2c. For example, 
if the application program 1a activates an instance of 
the Resource object type 2c, then the application pro- 
55 gram 1 b will use an instance of the Agent object type 2d 
to communicate with the application program 1a by at- 
taching the instance of the Agent object type 2d to the 
instance of the Resource object type 2c associated with 



7 



13 



EP 0 713 177 A1 



14 



the application program 1a. The object model tor the 
Agent object type 2d is shown in Fig. 15. As shown in 
Fig. 1 5, the Agent object type 2d includes the behaviors 
attach, detach, send and receive. The attach behavior 
attaches the instance of the Agent object type 2d asso- 
ciated with the application program 1b to the instance 
of the Resource object type 2c associated with the soft- 
ware application program la thereby enabling commu- 
nications between the two application programs. 

The detach behavior detaches the instance of the 
Agent object type 2d associated with the applications 
program 1b from instance of the Resource object type 
2c associated with the applications program 1 a thereby 
disabling communication between the two application 
programs. Using the send behavior, the application pro- 
gram 1 a sends data to the attached application program 
1b through the associated instance of the View object 
type 2e. Using the receive behavior, the application pro- 
gram la receives data from the attached application pro- 
gram 1 b. The application program 1 b can be associated 
with multiple instances of the Agent object type 2d. each 
instance of the Agent object type 2d associated with one 
or a multiple number of different application programs 

The dynamic model for instances ofthe Agent object 
type 2d is shown in Figs. 16-19. As shown in Fig 16. 
the instance of the Agent object type 2d transitions be- 
tween three states: a Dormant state I6a : an Attaching 
state 16b, and an Active state 16c. 

When an application program 1b successfully cre- 
ates an instance of the Agent object type 2d, the in- 
stance of the Agent object type 2d transitions to the Dor- 
mant state 1 6a. When creating the instance of the Agent 
object type 2d, the application program lb references 
an associated instance of the Adapter object type 2b. 
Once in the Dormant state 1 6a, the instance of the Agent 
object type 2d may either transition to the Attaching 
state 16b or be deleted. 

The attach event is triggered when the application 
program 1b issues the attach behavior only if the asso- 
ciated instance of the Adapter object type 2b is in the 
Active state 6c. During the Attaching state 16b, the 
Transport Framework implementation 1c performs the 
steps required to attach the application program 1b to 
the application program 1a corresponding to the given 
identification. 

When processing has completed for the Attaching 
state 16b, the attach-done event is triggered. If the re- 
sulting Error attribute value is failure then the instance 
of the Agent object type 2d transitions to the Dormant 
state 16a. Otherwise, the instance of the Agent object 
type 2d transitions to the Active state 16c. 

The Active state 1 6c, as further illustrated in Fig. 1 7, 
includes two states: Listening 17a and Processing 17b. 
Once in the Active state 16c, the instance of the Agent 
object type 2d can be in either the Listening state 17a 
or the Processing state 17b. The instance of the Re- 
source object type 2c triggers the transition of the in- 
stance of the Agent object type 2d to the Listening state 



17a during which time the instance of the Agent object 
type 2d awaits action from the software application pro- 
gram 1b. The software application program 1b causes 
the transition of the instance of the Agent object type 2d 
5 to the Processing state 17b. The other events are the 
results of activities in other states (except for the detach- 
by-view event which is sent by the instance of the View 
object type 2e). 

Once the Agent object type 2d is in the Active state 
to 16c, the application program 1b may trigger the send or 
receive events by issuing the send or receive behavior, 
respectively. The events may occur concurrently, not 
only between themselves, but with themselves. For ex- 
ample, an application program 1b can trigger two send 
'5 or two receive events, all concurrently. 

The Processing state 1 7b is further illustrated in Fig. 
18. As shown in Fig 18, the Processing state 17b in- 
cludes a Sending state 18a, a Receiving state 18b and 
a Detaching state 18c. The Agent object type 2d can be 
20 in any or all of these states simultaneously. However, 
neither the Sending state 18a nor the Receiving state 
16b may be entered ifthe Agent object type 2d is in the 
Detaching state 18c. 

During the Sending state 1 8a, the Transport Frame- 
25 work implementation 1c performs the steps required by 
the communications network implementation 1 d to send 
data to the attached applications program 1b. When the 
processing is complete, the send-done event is trig- 
gered. 

50 During the Receiving state 18b, further illustrated in 
the dynamic model shown in Fig. 19, the Transport 
Framework implementation 1c performs any steps re- 
quired by the communication network implementation 
1d to receive data from the attached application pro- 

35 gram 1b. When the processing is complete for the re- 
ceive behavior the receive-done event is triggered. 

The instance of the Agent object type 2d transitions 
to the Detaching state 18c upon receipt of a detach 
event from the software application program 1a which 

^0 initiated creation of the instance of the Agent object type 
2d. The applications program la triggers the detach 
event when issuing the detach behavior. 

When the detach event is triggered, the instance of 
the Agent object type 2d transitions to the Detaching 

45 state 1 8c during which the Transport Framework imple- 
mentation 1 c performs the steps necessary for the com- 
munications network implementation 1d to detach the 
attached applications program 1b. When detaching is 
complete and all sends and receives have issued their 

50 send-done and receive-done events, respectively, a de- 
tach-done event is triggered. 

VIEW 

5S One purpose ofthe View object type 2e is to provide 
the applications program 1a with a means to send data 
to and receive data from the applications program 1b 
which has attached an instance of the Agent object type 
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in Fig, 21. 

A detach-by-resource event is triggered from within 
the Transport Framework implementation 1c when an 
instance of the Resource object type 2c in the Waiting 
state lid receives the detach-by-agent event. Receipt s 
of the detach-by-resource event while the instance of 
the View object type 2e is in the Listening state 22a, also 
transitions the instance of the View object type 2e from 
the Listening state 22a of the Active stale 21b to the 
Dormant state 21a. 10 

Once the instance of the View object type 2e is in 
the Dormant state 21a, the only transition, as shown in 
Fig. 21, is to delete it. The delete is triggered from the 
instance of the Resource object type 2c after triggering 
the deactivate event or receiving the remove-view is 
event. 

Fig. 23 illustrates in detail the Processing state 22b 
ofthe Active state 21b. The Sending stale 23a : Receiv- 
ing state 23b and Detaching state 23c can occur con- 
currently The sync point at 23f indicates that both the 20 
all-sends-done event and the all-receives-done event 
must happen before transitioning out of the Processing 
state 23b. The sync point at 23g indicates that the all- 
sends-done, the all-receives-done and the completion 
of the processing by the Detaching state 23c can also 25 
transition the instance of the View object type 2e out of 
the Processing state 22b. Associated instances of the 
Agent object type 2d and associated instances of the 
Resource object type 2c are notified appropriately 

The behaviors associated with the Sending state so 
23a, the Receiving state 23b and the Detaching state 
23c are provided by the particular implementation of the 
Transport Framework implementation 1c. 

DATA 35 

Fig. 25 shows an object model for the Data object 
type 2f. The Data object type 2f includes the behaviors 
putData(), putLenglh(), getDataAddress{) and 
getLengthQ. The behaviors putData and putLength 40 
place the data and the length of the data respectively 
into the memory 1x of the general purpose digital com- 
puter. The behavior getLengthQ returns the length ofthe 
stored data from memory 1x. The behavior getDataAd- 
dress() returns the address in memory where the data 45 
starts. The data is thus stored contiguously in the com- 
puter memory 1x. 

Fig. 26 illustrates an exemplary application program 
26a and it's association with instances of the object 
types which comprise the Transport Framework of the so 
present invention. The exemplary application program 
26a creates and owns instances of the Adapter object 
type 2b, the Agent object type 2d, the Resource object 
type 2c, the Data object type 2f and the Name Space 
Iterator object type 2a. instances of the View object type ss 
2e, however, are created and owned by the Transport 
Framework implementations 1c. The application pro- 
gram 1 a only references the instances of the View object 
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type 2e when using them. The number of instances of 
the object types and which of the object types are in- 
stantiated depend upon the behavior the application 
program 1a desires from the Transport Framework im- 
plementation 1c. 

Fig. 27 illustrates an exemplary application of the 
Transport Framework implementation 1c of the present 
invention for a simple client-server protocol where the 
protocol in the server application 27a can handle multi- 
ple client applications 27b, but the client application 27b 
can only communicate with one server application 27a. 
The server application 27a thus creates one instance of 
the Adapter object type 2b, one instance of the Re- 
source object type 2c. For each client application 27b 
that attaches to the server application 27a, one instance 
of the View object type 2e is also created. Instances of 
the Data object type 2f are created to hold the actual 
data transmitted. 

The client application 27b creates one instance of 
the Adapter object type 2b, one instance of the Name 
Space Iterator object type 2a and one instance of the 
Agent object type 2d. One or more instances of the Data 
object type 2f are also created when communicating 
with the server application 27a through the Agent object 
type 2d to hold the actual data transmitted. 

To simplify the exemplary client/server application 
shown in Fig. 27, the client application 27b does not 
need the Name Space Iterator object type 2a if the com- 
plete Resource Name for the instance of the Resource 
object type 2c associated with the serverapplication 27a 
were available to the client application 27b. 



Claims 

1. A computer implemented system for providing a 
common communications interface between a plu- 
rality of programs through a communications net- 
work, the system comprising: 

adapter means responsive to a first one of said 
plurality of programs for connecting said first 
one of said plurality of programs to said com- 
munications network; 

resource means coupled to said adaptor 
means and associated with said first one of said 
plurality of programs for storing at least one 
identifier associated with said first one of said 
plurality of programs in a memory and respon- 
sive to an agent means associated with a sec- 
ond one of said plurality of programs for gener- 
ating view means associated with said second 
one of said plurality of programs to accept com- 
munications from said second one of said plu- 
rality of programs through said communica- 
tions network; 

view means coupled to said resource means 
and responsive to said second one of said plu- 
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rality of programs for accepting data transmit- 
ted from said second one of said plurality of pro- 
grams to said first one of said plurality of pro- 
grams; and 

data means coupled to said view means for $ 
storing said data transmitted between said first 
one of said plurality of programs and said sec- 
ond one of said plurality of programs. 

2. The system in accordance with Claim 1 , wherein 10 

agent means are coupled to said adaptor 
means and to said resource means and 
responsive to said first one of said plurality of 
programs for attaching said first one of said plu- is 
rality of programs to said resource means asso- 
ciated with a third one of said plurality of pro- 
grams thereby initiating communications with 
said third one of said plurality of programs; 
said view means being coupled to said agent 20 
means and to said resource means; and 
said data means being coupled to said agent 
means and said view means for storing said 
data transmitted between said first one of said 
plurality of programs and said third one of said 25 
plurality of programs. 

3. The system in accordance with Claims 1 -2, further 
comprising; 

30 

name space iterator means coupled to said 
adapter means and associated with said com- 
munications network for searching said mem- 
ory of said computer for one of said at least one 
identifier associated with said resource means 35 
in response to said agent means. 

4. The system in accordance with Claim 3. wherein 
said third one of said plurality of programs corre- 
sponds to one of said identifiers. 40 

5. The system in accordance with Claims 14, wherein 
said first one of said plurality of programs and said 
second one of said plurality of programs share said 
address space in a processor of said computer 4S 

6. The system in accordance with Claims 14 : wherein 
said first one of said plurality of programs and said 
second one of said plurality of programs occupy dif- 
ferent sections of address space in said processor so 
of said computer. 

7. The system in accordance with Claims 1 -6 ; wherein 
said communications network includes a network 
implementation selected from the group containing; 55 
a PIPES Platform network implementation, Win- 
Sock network implementation, CPI-C network 
implementation, NetBEUI network implementation 



or a combination of one or more implementations 
thereof 

8. The system in accordance with Claims 1 -7, wherein 
said adapter means further includes first memory 
means for storing references to said agent means 
associated with said adapter means; and second 
memory means for storing references to said 
resource means associated with said adapter 
means. 

9. The system in accordance with Claims 1 -8, wherein 
said resource means further includes memory 
means for storing references to said view means 
associated with said resource means. 

10. A method of providing data communication 
between a plurality of programs through a commu- 
nications network, comprising; 

connecting a first one of said plurality of pro- 
grams to said communications network using 
an adapter means; 

initializing said first one of said plurality of pro- 
grams for receiving communications from a 
second one of said plurality of progra ms using 
a resource means associated with said first one 
of said plurality of programs; 
attaching said second one of said plurality of 
programs to said resource means associated 
with said first one of said plurality of programs 
using an agent means associated with said 
second one of said plurality of programs; 
generating a view means in response to said 
agent means associated with said second one 
of said plurality of programs for transmitting 
data to and receiving data from said second 
one of said plurality of programs; 
storing said data in a data means associated 
with said first one of said plurality of programs. 

11. The method in accordance with Claim 10, compris- 
ing; 

storing at least one identifier associated with 
said first one of said plurality of programs in 
said memory of said computer in response to 
said connecting step. 

12. The method in accordance with Claims 10-11, fur- 
ther comprising; 

searching said memory for said at least one 
identifier associated with said first one of said 
plurality of programs in response to an agent 
means associated with a second one of said 
plurality of programs. 
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13. The method in accordance with Claims 10-12, fur- 
ther comprising; 

transmitting data to and receiving data from 
said second one of said plurality of programs 5 
using said view means. 
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